home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 14378 < prev    next >
Encoding:
Text File  |  1996-08-05  |  1.6 KB  |  38 lines
  1. Newsgroups: comp.lang.c++,comp.os.ms-windows.programmer.win32
  2. Path: netcom.com!alan
  3. From: alan@netcom.com (Robert Alan Wright)
  4. Subject: Re: VC++ 4.0 memory allocation slower than in 2.x!!!
  5. Message-ID: <alanDp1uEB.JHs@netcom.com>
  6. Organization: NETCOM On-line Communication Services (408 261-4700 guest)
  7. References: <alanDozpsy.Kn6@netcom.com> <4jgde4$kgo_001@chem.uva.nl> <315C86C3.57BE@sdt.com>
  8. Date: Fri, 29 Mar 1996 21:58:59 GMT
  9. Sender: alan@netcom14.netcom.com
  10.  
  11. In article <315C86C3.57BE@sdt.com>, Larry Baker  <leb@sdt.com> wrote:
  12. >
  13. >Note that this has nothing to do with the actual performance of
  14. >malloc and free themselves; this has to do with the performance of
  15. >the routines that use the memory allocated *by* malloc.
  16. >
  17.  
  18. I received mail from a couple of people who actualy knew what the
  19. performance problem was. It turns out that the 4.0 C runtime maps
  20. malloc and realloc calls fairly directly to GlobalAlloc, thus
  21. slowing them down considerably. Apparently Microsoft thinks that
  22. everyone now has infinitely fast Pentiums and don't care about
  23. performance. Unfortunately, my customers do care a lot about the
  24. speed of the application in question.
  25.  
  26. In any case, the old libc code which does fewer GlobalAllocs and then
  27. suballocates is still in the libc source. I just had to rebuild libc 
  28. with the WINHEAP=NO option to get the old behavior back. I also had
  29. to fix a compilation error for malloc.c (missing include), I guess
  30. Microsoft didn't bother to check that this still worked :-(.
  31.  
  32. The net result is that the app is now actually faster than before,
  33. no thanks to Microsoft (although I guess they did improve the code
  34. generator).
  35.  
  36. Alan
  37.  
  38.